icp_server/observability_service.bal (2)

176-184: Extract the user context before resolveRuntimeIds to fail fast.

resolveRuntimeIds already hits the DB (potentially multiple storage:getRuntimes calls under a component×environment cross-product). If the Authorization header is malformed or extractUserContextV2 fails, that work is wasted and the same logic is duplicated across the logs and metrics handlers.

Moving the user-context extraction above resolveRuntimeIds in both resource functions also narrows the auth-vs-data ordering: every request that reaches the storage layer will have already produced a validated userId, which simplifies future auditing/logging and reduces the DoS surface for tokens that decode but are semantically invalid.

♻️ Suggested ordering (logs handler)

     resource function post logs(http:Request request, types:ICPLogEntryRequest logRequest) returns types:LogEntriesResponse|http:Response|error {
         log:printDebug("Received log request: " + logRequest.toString());
 
+        types:UserContextV2 userContext = check extractUserFromObservabilityRequest(request);
+
         // Transform ICPLogEntryRequest to LogEntryRequest by resolving component/environment filters to runtime IDs
         string[] runtimeIdList = check resolveRuntimeIds({
                                                              componentId: logRequest.componentId,
                                                              componentIdList: logRequest.componentIdList,
                                                              environmentId: logRequest.environmentId,
                                                              environmentList: logRequest.environmentList
                                                          });
-
-        types:UserContextV2 userContext = check extractUserFromObservabilityRequest(request);
         runtimeIdList = check filterRuntimeIdsForUser(userContext.userId, runtimeIdList);

Apply the analogous change at lines 262-270 for the metrics handler.

Also applies to: 262-270

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@icp_server/observability_service.bal` around lines 176 - 184, Move the user
extraction to run before DB work: call
extractUserFromObservabilityRequest(request) and assign types:UserContextV2
userContext before invoking resolveRuntimeIds so malformed/invalid auth fails
fast; then pass userContext.userId into filterRuntimeIdsForUser as you already
do. Apply the same reorder in the metrics handler (the analogous block that
calls resolveRuntimeIds and filterRuntimeIdsForUser) so extraction of
userContext always happens prior to resolveRuntimeIds.

---

134-147: N+1 database roundtrips per request under filterRuntimeIdsForUser.

storage:hasAccessToRuntime issues ~3 DB queries per runtime (runtime lookup + integration-access view + optional environment restriction). Called sequentially in this loop, a query that resolved M runtimes will incur ~3M synchronous roundtrips before the adapter is even called, which can dominate request latency for broad component/environment filters and contradicts the "keep performance stable" goal stated in the PR objectives.

Consider a single batch authorization check that scopes directly in SQL, e.g. an IN (?, ?, ...) join against v_user_integration_access (plus environment restriction) that returns the subset of accessible runtime IDs in one roundtrip. This also avoids partial-failure states where some checks succeed and a later one errors out, leaving the caller unsure whether partial filtering occurred.

♻️ Sketch (pseudo-API)

-isolated function filterRuntimeIdsForUser(string userId, string[] runtimeIds) returns string[]|error {
-    string[] filtered = [];
-    foreach string rid in runtimeIds {
-        boolean|error allowed = storage:hasAccessToRuntime(userId, rid);
-        if allowed is error {
-            return allowed;
-        }
-        if allowed {
-            filtered.push(rid);
-        }
-    }
-    return filtered;
-}
+isolated function filterRuntimeIdsForUser(string userId, string[] runtimeIds) returns string[]|error {
+    if runtimeIds.length() == 0 {
+        return runtimeIds;
+    }
+    // Single DB roundtrip returning only the subset of runtimeIds the user can access.
+    return storage:filterAccessibleRuntimes(userId, runtimeIds);
+}

Implementation on the storage side would be roughly:

SELECT r.runtime_uuid
FROM runtimes r
JOIN v_user_integration_access v
  ON v.integration_uuid = r.integration_uuid AND v.user_uuid = ?
LEFT JOIN <env_restriction_view> e
  ON e.user_uuid = v.user_uuid AND e.integration_uuid = r.integration_uuid
WHERE r.runtime_uuid IN (?, ?, ...)
  AND (r.env_uuid IS NULL OR e.env_uuid IS NULL OR e.env_uuid = r.env_uuid);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@icp_server/observability_service.bal` around lines 134 - 147, The current
filterRuntimeIdsForUser loops and calls storage:hasAccessToRuntime per runtime
causing N+1 DB roundtrips; replace this with a single batch storage call that
returns the subset of accessible runtime IDs in one query (eg. add/use a storage
method like storage:getAccessibleRuntimeIds(userId, runtimeIds) or
storage:filterAccessibleRuntimes(userId, runtimeIds) which implements an IN(...)
join against v_user_integration_access with the environment restriction), then
have filterRuntimeIdsForUser call that single method, propagate any error
directly, and return the resulting string[] to avoid partial-success states and
make authorization one roundtrip.